The present invention is related to service buses, and in particular to an activity-oriented service bus.
A service-oriented architecture (SOA) is an architecture commonly employed to allow consumers of services to communicate with a plurality of services without requiring the service consumers to make function calls directly to service providers. Communication between the plurality of loosely coupled software services is made possible by a service bus, such as the enterprise service bus (ESB). The concept of a service bus employed in SOA systems is derived from use of the word “bus” in hardware applications, in which the hardware bus allows various components to communicate with each other across the bus, and allows components to be plugged in and out without problem. The goal of the service bus is to allow the plurality of loosely coupled software services to be able to communicate with one another and to allow software services to be added and subtracted without problem.
The main responsibilities of a service bus include interfacing with the service providers/consumer, converting messages between the different protocols employed by the various service providers/consumers, and routing messages between various service providers/consumers.
Development of a typical SOA architecture requires a user to create a service definition document that describes the services provided by service providers. For example, a Web Services Description Language (WSDL) is an example of this type of document, wherein the WSDL describes the operations that are available to service consumers to invoke. A service provider that wishes to invoke a service provider needs access to the service definition implemented by the service provider during an implementation or development phase. As a result, the service consumer is tightly bound to the service definition, which complicates changes to implementation of service providers. For example, updating a service provider requires creation of a new service definition and may require continued maintenance of multiple service definitions to accommodate service consumers utilizing different versions of the same service.
That is, a typical service bus can be described as playing a passive role as connector between service provider and service consumers. Complex interactions between consumers and providers are left to implementation outside of the service bus. Furthermore, typical SOA systems only allow one type of interaction between service consumer and service providers, wherein a service consumer makes a function call to a service provider. While the service bus may implement protocol conversion and/or data transformation, the general use pattern remains a client-server type relationship.